Unified Extensible Firmware Interface (UEFI) is a specification created by a non-profit industry body detailing a programming interface between the Operating System (OS) and the included firmware of a computing device such as (but not limited to) a Personal Computer (PC). UEFI specifications describe a set of tools by which a computing device can move in an organized fashion from the power-applied state to fully operational. The computing device is initialized by firmware included within the device and this firmware provides a range of software services which facilitate the boot of the operating system. The UEFI specification tells the desired result but deliberately does not specify the internal tactic of implementation. The UEFI firmware specification replaces earlier OS/firmware interfaces previously used by the industry and commonly known as legacy BIOS.
The UEFI specification provides a facility called driver signature checking by which software from other parties can be ‘signed’ using public/private key cryptographic techniques at its origin. This signature is validated by the computing device firmware prior to allowing this software to operate. The signature checking concentrates on software added to configure optional components (plug-in boards) and software supplied by the operating system for early boot steps (i.e.: OS boot loaders). The signature checking is accomplished with a library of approved keys. The computing device must take care to not allow unauthorized software elements any ability to modify the library of approved keys as this would allow rogue software elements to defeat the signature checking.
When implemented in a computing device, the machine codes for UEFI firmware and all permanent data used by the firmware reside in Read Only Memory (ROM). In many cases the ROM is an Electrically Erasable silicon device known as a flash ROM. Flash ROM has the characteristic that it can be erased by electrical command and individual elements may then be written and the device will retain the data indefinitely. When power is first applied to the computing device, the system executes a process called reset which clears the state to a known condition and begins execution of the firmware. The firmware is read from the flash ROM. Among other services, the firmware is responsible for operation of the computing device until a boot process can be run which loads an operating system for the computing device into memory. Once loaded, the operating system is in charge of normal operation of the computing device.
The Flash ROM is partitioned into several functional divisions or regions. One such region is the code store which must be protected from alteration by any entity except for entities that have been authorized to update the code store. A second region that is called the Authenticated Variable Region or Store holds Authenticated Variables defined in the UEFI specification and is used to hold UEFI-defined security information (the system security database). In addition to the UEFI-defined information the Authenticated Variable Store can be used to store user-defined data related to the ultimate uses of the computer. Because it contains security data and potentially sensitive user data the UEFI specification provides that the Authenticated Variable Region/Store must be protected from alteration by any entity except those authorized by the presence of identifying key data within the system security database. A third region, the UEFI variable store, contains lower security information which may be freely updated by user programs.
A computing device may also contain one or more elements known as Central Processing Units (CPU) which, when in operation, can read from and also erase and/or write the flash ROM. The CPU has a normal operating mode and a second operating mode called System Management Mode (SMM). When the CPU is in normal operating mode it can access all elements of the computer except certain memory regions exclusively dedicated to SMM. In contrast, when the CPU is operating in SMM it is able to access all elements of the computing device including the dedicated memory. An electrical signal is made available within the circuitry of the computing device which can indicate when the CPU is operating within SMM. The CPU device may be directed to transition from normal operating mode to SMM by a number of triggers called System Manage Interrupt (SMI) events including SMI events triggered by firmware. The exact triggers available differ somewhat from among system designs but the result when the platform appropriate trigger is used is that execution in main memory is immediately suspended and execution begins at a specific location in SMM memory. The computing device also contains a hardware circuit that can detect if the system is in SMM and is able to disable flash ROM erase and write operations when the system is not in SMM.
The UEFI specification provides for a secure boot process in which only validated executable code is executed during a boot sequence. The conventional UEFI secure boot process depends upon validation of executable code against a local system security database in an authenticated variable. During this process there is ordinarily only two ways in which the code can be validated and therefore approved for execution during the boot process. The first way to validate executable code is that the executable code is approved if the executable has been ‘signed’ by a certificate in the system security database. The same certificate may have been used to sign a large number of ‘executables’. The second way to validate executable code is that an exact hash of the executable that had been previously stored in the system security database matches a hash of the executable being offered for execution (each hash uniquely identifies only the code upon which it was based and any alteration to that code after the storing of the hash will result in a mismatch when comparing a hash of the altered code to the hash of the original code). Once validated, the executable code may be executed during the boot sequence. Code which is not validated through either mechanism is not allowed to execute during a conventional UEFI Secure Boot.
FIG. 1 (prior art) depicts an exemplary sequence of steps performed by a UEFI-compliant computing device to validate executable code prior to the code being executed during a conventional Secure Boot of the UEFI-compliant computing device. After firmware in the computing device initiates a boot sequence (step 102), the firmware identifies code to be executed, the “proposed executable code” (step 104). The boot sequence is stopped while the system security database is checked to see if it holds a certificate used to sign the proposed executable code (step 105). If a certificate used to sign the proposed executable code is present (step 105), the firmware authorizes the execution of the proposed executable code (step 108) and the boot sequence continues (step 112). On the other hand if a certificate used sign the proposed executable code is not present (step 105), the system security database is further checked to see if an exact hash of the proposed executable code is stored (step 107). If an exact hash of the proposed executable code is stored in the system security database (step 107), the firmware authorizes the execution of the proposed executable code (step 108) and the boot sequence continues (step 112). However, if an exact hash of the proposed executable code is not stored (step 107), the execution of the proposed executable code is not authorized and the boot sequence continues if possible without executing the proposed executable code (step 112).